ci(release): stage the back-merge branch instead of opening the PR - #126

Applies the same treatment as #125 to the post-release back-merge: stage the branch, hand the maintainer a prefilled link, do not open the PR.

Changes

gh pr create is removed. On a published release the workflow now pushes backmerge/main-to-develop-<run_id> at main's tip and writes a job summary containing a fully prefilled "open the PR" link — base develop, head the new branch, title and body both filled in.

permissions drops to contents: write, and the GH_TOKEN env goes away — nothing calls the API any more.

Why not open it here

Same reason as the release PR: a PR opened by github-actions[bot] with the default GITHUB_TOKEN does not trigger pull_request workflows. CI, Integration Tests, and Commit Lint gate develop, so a bot-opened back-merge would land unverified.

One deliberate difference from prepare-release

prepare-release commits its PR body to .github/release-pr/<tag>.md, because that body embeds the version's changelog section and is far too long for a URL query string.

The back-merge body is a single boilerplate sentence, so it fits in the URL and is prefilled directly. Nothing to copy, and no file accumulating in the repo for what is pure bookkeeping. The header comment records that reasoning so the two workflows do not get "unified" later without cause.

Also: a no-op guard

The old workflow pushed a branch and attempted a PR unconditionally. If develop already contained every commit on main — the normal outcome when the release PR was a fast-forward promotion — that produced a branch with an empty diff and a failed gh pr create.

It now checks first and, when there is nothing to back-merge, pushes no branch and says so in the summary. As of today git rev-list --count origin/develop..origin/main is 0, so this is the live case, not a hypothetical.

🤖 Generated with Claude Code